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(54) Method and apparatus for longest matching prefix determination in a communication 
network 



(57) A method and apparatus for compressing the 
data associated with trie cuts (strides), and a method 
and apparatus for utilizing such compressed data to de- 
termine forwarding decisions for data packets in a com- 
munication network are presented. The compression 
technique presented generates a pair of bitmaps and a 
pair of base pointers for each set of compressed data. 
The bitmaps are compared with a portion of the address 
to ascertain whether the forwarding decision is deter- 
mined within this portion of the trie. Forwarding deci- 
sions are stored in a leaf table that is accessed via a 
leaf table index. The leaf table index is generated by 



combining a leaf table offset generated from at least one 
of the bitmaps with a leaf table base pointer included in 
the stride block. Thus, if the forwarding decision is de- 
termined within the stride, the leaf table will be accessed 
via the leaf table index to retrieve the forwarding deci- 
sion. If the forwarding decision is not completely deter- 
mined within the stride, a branch table is used to deter- 
mine the location of the subsequent stride to be proc- 
essed. The branch table is accessed via a branch table 
index generated by combining the branch table base 
pointer of the stride with a branch table index generated 
from one or more of the bitmaps included in the stride 
block. 
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Description 

Field of the Invention 

[0001] The invention relates generally to communica- 
tions networks and more particularly to a method and 
apparatus for longest matching prefix determination in 
communications networks. 

Background of the Invention 

[0002] Data communications networks utilize ad- 
dresses to forward packets of information between us- 
ers. As data communication networks continue to 
evolve, the number of addresses supported, the amount 
of traffic, and the speed with which the traffic is traveling 
are all increasing. As such, routers in such communica- 
tions networks must determine sources and destina- 
tions of endstations associated with traffic more quickly 
than in the past. 

[0003] Routing data packets in Internet Protocol (IP) 
networks requires determining the best matching prefix 
corresponding to the source and destination addresses 
for the packet, which may also be referred to as deter- 
mining a longest prefix match (LPM) for the addresses. 
Routers that forward packets typically include a data- 
base that stores a number of address prefixes and their 
associated forwarding decisions that indicate where the 
data should be sent next (next hops). When the router 
receives a packet it must determine which of the prefixes 
in the database is the best match for the packet. 
[0004] Binary tries have commonly been used for de- 
termining the LPM for data packets. Figure 1 illustrates 
a basic binary trie structure that includes a set of binary 
prefixes. The example trie illustrated in Figure 1 corre- 
sponds to a six-bit address space that is used to simplify 
the discussion. The shaded circles indicate valid prefix- 
es. The binary trie illustrated in Figure 1 contains a de- 
fault route corresponding to the root of the trie and a 
plurality of valid prefixes that may only be partially spec- 
ified (e.g. OOOXXX), or fully specified (e.g. 000100). 
Bits included in the address to be resolved are used to 
make branching decisions at each of the nodes within 
the trie, where 0 bits cause a branch to the left and one 
bits cause a branch to the right. As is illustrated, the bi- 
nary prefix OOOXXX is a valid prefix, as is the prefix 
0001 00. Although a packet that has an address that 
matches the prefix 000100 would also match the valid 
prefix OOOXXX, the longest matching prefix is 000100, 
and thus 000100 is the prefix which must be selected 
for the address. 

[0005] Figure 2 illustrates a prior art technique for sim- 
plifying the basic binary trie illustrated in Figure 1 . Figure 
2 illustrates a Patricia trie that flattens the basic binary 
trie in areas where decisions at nodes within the trie 
structure cannot result in more than one possible prefix 
determination. In other words, nodes within the trie 
structure that are traversed in route to a valid prefix with 



no further decision making required are compressed 
out. Such path compression can reduce the average 
number of memory accesses required to determine the 
LPM for an address to lop^N accesses, where N is the 

5 number valid prefixes stored in the trie. However, in the 
worst case when a path cannot be compressed, Patricia 
trees may require L memory accesses to resolve an 
LPM, where L is equal to the number of bits in the ad- 
dress, which may be 32 bits in some applications such 

10 as IP version 4 and 128 bits for IP version 6. The varia- 
bility in the number of memory accesses requires 
presents problems for high-speed router design. Fur- 
thermore, even if all LPM determinations could be made 
with log^N memory accesses, the memory bandwidth 

is requirements would still make router design impractical 
when high link rates must be supported. 
[0006] Another trie processing method that attempts 
to reduce the time it takes to determine the appropriate 
prefix is to create a multi-way branching trie that proc- 

20 esses multiple bits of the address in a single step. This 
is illustrated in Figure 3, where a trie that exists in a 
32-bit address space has been broken into a set of 
steps, or strides. As is illustrated, the strides may be se- 
lected to be of varying bit lengths. Thus, 4-bit strides, 

25 8-bit strides, and even 16-bit strides may be employed 
to traverse the trie structure. For each stride, a portion 
of the address is compared with sets of bits correspond- 
ing to that stride to determine if a LPM has been resolved 
or if one or more additional strides must be traversed in 

30 order to determine the LPM. 

[0007] In order to be able to process a number of ad- 
dress bits in a stride, prefix expansion must be per- 
formed so that there is a valid prefix for each binary val- 
ue at the cut depth for the stride, where the cut depth is 

35 determined by the size of the stride. Figure 4 shows the 
root level of a 5-bit portion of a trie structure after pref ix 
expansion. The cut depth is the bottom set of prefixes 
of the trie structure illustrated in Figure 4 and is shown 
surrounded by a long rectangular box. In order to have 

40 valid prefixes at all of the nodes at the cut level, new 
nodes may have to be created at the cut depth in order 
to make the trie complete. Values for newly created 
nodes are then propagated from parent nodes. Propa- 
gation of a prefix value to a newly created node is illus- 

4 5 trated via the arrows originating from parent nodes. One 
example is the labeled parent node that propagates a 
valid prefix to the three labeled propagated nodes. As 
can be seen, the highest level, or root node also serves 
as a parent node to some of the nodes at the cut level. 

so [0008] Those nodes in the trie structure of Figure 4 
that represent a final prefix match and a resolved for- 
warding decision are represented by a shaded circle, 
whereas those nodes that indicate the next stride must 
be accessed in order to continue towards determination 

55 of a forwarding decision are represented by shaded 
squares. Thus, shaded circles represent a point at which 
the search for prefix match is terminated, whereas shad- 
ed squares indicate that the prefix match must exist at 
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a deeper level in the overall trie structure and therefore 
the search is extended. 

[0009] Because 2 N valid prefixes are typically stored 
to process an N-bit stride, larger strides require a great 
deal of memory, which can be a limiting factor in the 
stride size chosen. Smaller strides require, on average, 
more memory accesses to ascertain the forwarding de- 
cisions. Thus, there is a trade-off between the amount 
of memory required to store the data for a trie structure 
and the number of memory accesses required to com- 
pletely traverse the trie structure to the appropriate end 
prefix. 

[001 0] Therefore, a need exists for a method and ap- 
paratus that reduces the memory required to store val- 
ues associated with strides in trie structures such that 
prefix matching can be performed using a minimal 
number of memory accesses. 

Brief Description of the Drawings 

[0011] 

Figure 1 illustrates a graphical representation of a 

prior art binary trie structure; 

Figure 2 illustrates a graphical representation of a 

prior art Patricia trie structure; 

Figure 3 illustrates a graphical representation of a 

prior art trie structure broken into a number of 

strides; 

Figure 4 illustrates a graphical representation of a 
prior art prefix-expanded trie; 
Figure 5 illustrates compression of the stride results 
for a trie cut to a set of compressed stride results in 
accordance with a particular embodiment of the 
present invention; 

Figure 6 illustrates a graphical representation of a 
trie cut associated with a stride that includes com- 
pressed nodes; 

Figure 7 illustrates the further compression of com- 
pressed stride results into a stride record and cor- 
responding leaf and branch tables in accordance 
with a particular embodiment of the present inven- 
tion; 

Figure 8 illustrates an alternate form of further com- 
pression of the compressed stride results into a 
stride record that includes sub-tries and a corre- 
sponding leaf pointer table in accordance with a 
particular embodiment of the present invention; 
Figure 9 illustrates a graphical representation of a 
trie cut with compressed nodes that distinguishes 
between subsequent dense and sparse stride 
records in accordance with a particular embodiment 
of the present invention; 

Figure 10 illustrates a graphical representation of a 
sparse stride record in accordance with a particular 
embodiment of the present invention; 
Figure 11 illustrates a graphical representation of a 
dense stride record in accordance with a particular 



embodiment of the present invention; 
Figure 12 illustrates a graphical representation of a 
dense block in accordance with a particular embod- 
iment of the present invention; 

5 Figure 13 illustrates a flow diagram of a method for 
compressing stride data in accordance with a par- 
ticular embodiment of the present invention; 
Figure 14 illustrates a block diagram of a packet 
routing circuit in accordance with a particular em- 

10 bodiment of the present invention; 

Figure 15 illustrates a block diagram of a packet 
routing processor in accordance with a particular 
embodiment of the present invention; 
Figure 16 illustrates a flow diagram of a method for 

15 packet routing in accordance with a particular em- 
bodiment of the present invention; 
Figure 17 illustrates a flow diagram of a method for 
processing a dense stride record in accordance 
with a particular embodiment of the present inven- 

20 tion; and 

Figure 18 illustrates a graphical representation of 
the determination of a forwarding decision for a par- 
ticular address in accordance with a particular em- 
bodiment of the present invention. 

25 

Detailed Description of a Preferred Embodiment of 
the Invention 

[0012] Generally, the present invention provides a 

30 method and apparatus for compressing the data asso- 
ciated with trie cuts (strides), and a method and appa- 
ratus for utilizing such compressed data to determine 
forwarding decisions for data packets in a communica- 
tion network. The compression technique presented 

35 generates a pair of bitmaps and a pair of base pointers 
for each set of compressed data. The bitmaps are com- 
pared with a portion of the address to ascertain whether 
the forwarding decision is determined within this portion 
of the trie. Forwarding decisions are stored in a leaf table 

40 that is accessed via a leaf table index. The leaf table 
index is generated by combining a leaf table offset gen- 
erated from at least one of the bitmaps with a leaf table 
base pointer included in the stride record. Thus, if the 
forwarding decision is determined within the stride, the 

45 leaf table will be accessed via the leaf table index to re- 
trieve the forwarding decision. If the forwarding decision 
is not completely determined within the stride, a branch 
table is used to determine the location of the subsequent 
stride to be processed. The branch table is accessed 

so via a branch table index generated by combining the 
branch table base pointer of the stride with a branch ta- 
ble index generated from one or more of the bitmaps 
included in the stride record. 

[0013] The method and apparatus described herein 
55 provide techniques for compressing data associated 
with stride records. Techniques are also described for 
storing the data in an efficient manner such that forward- 
ing decisions can be determined utilizing a minimal 
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number of memory accesses. The compression tech- 
niques described herein enable the data associated with 
large strides to be stored in an efficient manner such 
that the memory required to store the forwarding or 
branching decisions for each stride is greatly reduced 
in comparison to prior art solutions. As such, rapid de- 
termination of forwarding decisions can be performed in 
a system that utilizes memory efficiently such that large 
strides can be accommodated with a practical amount 
of memory in a system that can support high speed rout- 
ing. 

[0014] The invention can be better understood with 
reference to Figures 5-18. Figure 5 shows the list, or 
table of stride results 62 represents the corresponding 
pointers for each of the nodes in the extended trie struc- 
ture of Figure 4. At the top of the list, the leaf pointer for 
000XXX corresponds to the left most shaded circle in 
the cut level of the trie structure of Figure 4. The bottom- 
most entry in the list of stride results 62, a leaf pointer 
for 11 111 X, corresponds to the right most shaded circle 
at the cut level of the trie structure of Figure 4. 
[001 5] As can be seen from the list of stride results 62 
in Figure 5, there is a fair amount of repetition for certain 
entries. For example, the first two entries of the table of 
stride results 62 are the same. This is because these 
entries correspond to a pair of the propagated nodes 
that were created and tilted with the leaf pointer corre- 
sponding to the parent node. Similar sets of repeating 
pointers can be observed within the stride results 62. 
[0016] By recognizing that compression of the stride 
results 62 can be accomplished through a form of run 
length encoding, the amount of memory required to 
store the results for this 5-bit stride can be greatly re- 
duced. Figure 6 illustrates a compressed trie structure 
50 in which consecutive repetitive results are com- 
pressed to a single result. A bitmap 54 is used to indicate 
whether or not a result is stored for a particular node. 
For example, the first bit in the bitmap 54 is a one, thus 
indicating that results are included in the compressed 
set of results for the first node 52 at the cut level. 
[0017] As was seen in the table of stride results 62, 
the results for the second node 51 are the same as the 
result for the first node 52. As such, the bitmap stores a 
0 at the bit location corresponding to the second node 
51 . A 0 bit entry in the bitmap 54 corresponds to a node 
for which the result has been compressed and, as such, 
the associated pointer is not immediately available. In 
order to retrieve this compressed pointer, a search al- 
gorithm must search for the first non-compressed entry 
(as represented by a 1 bit) to the left of the compressed 
entry in the bitmap 54. The pointer returned at this entry 
is identical to that which would have been stored for the 
compressed entry in an uncompressed format. The 
closest set bit corresponds to a node for which valid re- 
sults are stored in the set of compressed stride results 
66 illustrated in Figure 5. This result is also applicable 
to the subsequent nodes for which a 0 is stored in the 
bitmap 54. As is illustrated, the compressed stride re- 



sults 66 greatly reduce the number of pointers that must 
be stored to represent the results for each of the nodes 
at the cut level in the expanded trie structure. The bitmap 
54 is used in conjunction with the set of compressed 

5 stride results 66 to determine the appropriate pointer for 
each of the nodes at the cut level. 
[0018] Many modern processors include a single cy- 
cle instruction that scans a register for the least or most 
significant bit set. When combined with masking of por- 

10 tions of the bitmap 54, such operations provide an easy 
means for determining the next higher bit set in a par- 
ticular bitmap with respect to a bit position selected by 
an address. 

[001 9] As stated above, in order to recover the appro- 

15 priate pointer, or result, for a node within the cut section 
of a stride, the bitmap 54 can be used in conjunction 
with the compressed stride results 66. If the compressed 
stride results 66 are individually stored in a contiguous 
fashion within memory, an appropriate pointer can be 

20 determined by calculating an offset within the set of con- 
tiguous compressed results based on the number of set 
bits in the bitmap 54 to the left of the desired bit location. 
Although this may be accomplished by sequentially 
scanning the bitmap 54 and counting the number of 1 *s, 

25 more efficient means for calculating the number of Vs 
in a particular set of bits are commonly available. In 
many processors, a population count (popcount) oper- 
ation may be available which calculates the number of 
1 *s in a set of bits. Thus, by masking off the lower section 

30 of the bitmap 54 below the selected bit location and per- 
forming a popcount on the remaining set of bits, an offset 
to the table of compressed stride results 66 can be de- 
termined. In processors that do not support a specific 
popcount operation, a simple linear set of instructions 

35 can be used to calculate the popcount for a set of bits. 
One such set of instructions is detailed in the GNU C 
library. 

[0020] Although the combination of the bitmap 54 and 
the set of compressed stride results 66 is illustrated in 

40 Figure 6 reduces the amount of memory required to 
store the results for a particular trie cut, or stride, two 
memory accesses are still required in order to determine 
a specific result for a node. One memory access to re- 
trieve the bitmap 54, and another to retrieve the appro- 

45 priate pointer from the list of compressed stride results 
66. Figure 7 illustrates a refinement on the data structure 
of Figure 6 in which an additional bitmap is added to the 
compressed record to indicate which of the pointers are 
leaf pointers. By storing the leaf pointers in a separate 

50 leaf pointer table and calculating an index to this table 
when a leaf is determined, the total number of memory 
accesses required can be reduced. 
[0021] Figure 7 illustrates the compressed stride re- 
sults 66 being further compressed into a stride block 70 

55 that includes a branch bitmap 72, a leaf bitmap 74, a 
leaf base pointer 75 and a set of branches 77 (sub-tries). 
"Block" is a term that may be used to describe a portion 
of the trie structure that includes the information for 
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processing a stride. A set bit in the branch bitmap 72 
indicates that the node corresponding to the bit location 
within the branch bitmap 72 has a result that corre- 
sponds to an entry in the list of branch pointers. A set 
bit within the leaf bitmap 74 indicates that the node to 5 
which the bit location within the leaf bitmap 74 corre- 
sponds has a result which is a leaf pointer stored in the 
leaf pointer table 76. If a leaf pointer needs to be refer- 
enced, a popcount can be used to determine an index 
within the leaf pointer table 76. This index can be com- w 
bined with the leaf base pointer 76, which points to the 
first entry of the leaf pointer table 76, in order to access 
the appropriate entry within the leaf pointer table 76. 
[0022] In order to eliminate the list of sub-trie pointers 
from the stride block 70, the subtires are placed in con- *s 
tiguous memory, and the individual sub-trie pointers are 
replaced by a bitmap and a base pointer to the contig- 
uous memory location. This is illustrated in Figure 8. The 
stride record 80 of Figure 8 has been reduced to the 
branch bitmap 72, the leaf bitmap 74, the leaf base 20 
pointer 75, and a branch base pointer 76. The branch 
base pointer 76 points to a base entry of a branch table 
89 (which also may be referred to as a next sub-trie 
block) that stores the branches (sub-tries) for the par- 
ticular stride. As was the case with the leaf pointer table 25 
76, the branch table 89 can be accessed through a com- 
bination of the branch base pointer 76 and an offset gen- 
erated using the branch bitmap 72. Thus, by masking 
off a' portion of the branch bitmap 72 and performing a 
popcount on the remaining portion, the appropriate off- 30 
set for the branch table 89 can be determined. 
[0023] The stride block 80 in the compressed format 
shown in Figure 8 is compact enough to fit within a cache 
line of a cache structure utilized by a processor for 
processing the stride. As is known in the art, an entire 35 
cache line (group of words) may be read from the cache 
in roughly the same time as is required to read a single 
word. This allows the stride to be processed in an effi- 
cient manner such that the forwarding decision for an 
address can be determined using a minimal number of 40 
memory accesses. Because of the compression per- 
formed, the amount of memory required to store the data 
required to process each stride is also greatly reduced 
in comparison with prior art solutions. 
[0024] In order to further optimize the storage of the 45 
results for a particular stride, a differentiation can be 
made between subsequent blocks, which must be proc- 
essed in order to determine the final forwarding deci- 
sion. Some strides of the overall trie structure may in- 
clude a small number of pointers that can be stored in so 
a small amount of memory. These sparse sections of 
the trie can be compressed into a particular sparse com- 
pression format that is more efficient in terms of 
processing as it may include the actual results for leaves 
rather than pointers to a leaf table. In order to take ad- 55 
vantage of the differentiation between sparse and dense 
blocks, the stride block that points to a subsequent 
sparse or dense block may include an encoding such 
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that the type of compression used for the subsequent 
blocks is known. Figure 9 illustrates a particular encod- 
ing technique that can be used to accomplish this differ- 
entiation. Figure 9 illustrates a stride that includes com- 
pressed nodes. Each node at the cut level can have one 
of four states. These four states are encoded through 
the combination of an extends bitmap 95 and a type bit- 
map 96 included in the stride record 99. For each node 
at the cut level, there is a bit within the extended bitmap 
95 and a bit within the type bitmap 96. The combination . 
of these two bits for each node indicates the particular 
state of that node. 

[0025] The extends and type bitmaps allow four states 
to be encoded for each node, which was not possible 
using the leaf and branch bitmaps as described thus far. 
As is apparent to one of ordinary skill in the art, the dis- 
tinction between the use of the branch and leaf bitmaps 
as opposed to type and extends bitmaps is solely de- 
pendent on whether different encoding of blocks (sparse 
vs. dense) is employed in the system. For embodiments 
that only use one block encoding, branch and leaf bit- 
maps provide enough encoded states. For embodi- 
ments that support sparse and dense blocks, extends 
and type bitmaps provide the necessary number of 
states to indicate the type of encoding for subsequent 
blocks. 

[0026] The first node is shown to have state that cor- 
responds to a leaf indication 91 . Nodes having a state 
corresponding to a leaf indication are shown as shaded 
circles. A leaf indication indicates that a valid entry is 
included within the leaf table for this particular node. A 
combination of the extends bitmap 95 and the type bit- 
map 96 will generate the leaf bitmap 74 described ear- 
lier, which can then be manipulated to determine an off- 
set for the leaf table. This offset can then be combined 
with the leaf base pointer 75 to access the leaf table and 
fetch the forwarding decision for the node from the leaf 
table. Leaf indications are encoded with a 0 in the ex- 
tends bitmap 95 and a 1 in the type bitmap 96. As is 
apparent to one of ordinary skill in the art, the particular 
bit encodings used in the examples described herein are 
arbitrary, and as long as the particular relationships be- 
tween different bitmaps are preserved, differing bit val- 
ues for various encodings may be utilized. 
[0027] The second node location is shown to corre- 
spond to an empty indication 94, which is illustrated as 
an unshaded circle. Empty indications are encoded with 
a 0 in the extends bitmap 95 and a 0 in the type bitmap 
96. An empty indication means that a search to the left 
must be performed to determine the appropriate result 
for this particular node as it has been compressed. 
[0028] The third node location at the cut level is shown 
to correspond to a sparse indication 92. Sparse indica- 
tions are indicated by a 1 in the extends bitmap 95 and 
a 0 in the type bitmap 96. A sparse indication means 
that the search extends beyond the cut level present in 
the trie structure 90. It further indicates that the subse- 
quent stride block fetched based on the index generated 
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for this node will be a sparse stride block, which, in one 
embodiment, may process a stride of 8 address bits. 
Knowing that the subsequent block to be fetched is a 
sparse block enables the processor to improve the effi- 
ciency with which the subsequent stride block is proc- 
essed. This is because additional information can be 
stored within the sparse block, as it does not include as 
many end results as a dense block. An example sparse 
stride block 901 is illustrated in Figure 10. 
[0029] The sparse block 901 includes a branch base 
pointer that points to the next block in the trie structure. 
The leaf base pointer included in the sparse block stores 
a base address for the leaf table. All leaves for the 
sparse block are stored contiguously from this base ad- 
dress, and can be accessed by generating an appropri- 
ate offset using the type and extends bitmaps. The sec- 
ond line of the sparse block is shown to include eight 
values. Each of these values can be directly compared 
with the portion of the address that is being used to re- 
solve this stride. If an exact match is found, then there 
is a pointer associated with that address in either the 
branch table or the leaf table. If no match it determined, 
a left search is performed such that the next highest val- 
ue in the array of values is selected, which is analogous 
to the scan bit operation on a bitmap. Because only eight 
values are stored within the sparse block, the type and 
extends bitmaps are each only 8-bit bitmaps. The use 
of the type and extends bitmaps is identical to that of a 
dense block, and they can be used to determine offsets 
to either the branch table or the leaf table, and the bit- 
maps can also be used to distinguish between sparse 
and dense subsequent blocks. 
[0030] Returning to Figure 9, the sixth bit location 
within the cut level of the stride is shown to correspond 
to a dense indication 93. The dense indication 93 is in- 
dicated by a 1 in the extends bitmap 95 and a 1 in the 
type bitmap 96. A dense indication 93 indicates that an 
offset should be generated and combined with the 
branch base pointer 76 to reference a subsequent stride 
block that is a dense block. The stride block 99 of Figure 
9 is a dense stride block in that it includes a full extends 
bitmap and type bitmap for all of the nodes at the cut 
level for the stride. This is in contrast to a sparse block 
that only includes a limited set of values corresponding 
to a limited set of nodes, and the appropriate type and 
extends bitmaps for those particular values. 
[0031] As stated earlier, a block is a portion of the trie 
structure that is used to process a stride. A block can 
be divided into a number of records where a particular 
record is selected by a portion of the address bits used 
to step through the stride. For example, a block for an 
8-bit stride may be divided into eight records where 
three of the eight address bits used to process this stride 
are used to select a specific one of the records within 
the block corresponding to the stride. The remaining five 
bits could then be used to process the record selected, 
where the structure of the record may be similar to the 
structures described thus far for a 5-bit block. In other 



words, each record could be structured as a block in that 
it would include bitmaps and base pointers. Figure 11 
illustrates a dense record 911. The differentiation be- 
tween blocks and strides will be further explained with 

5 reference to Figure 1 8 below. 

[0032] The dense record 91 1 includes an extends bit- 
map, a type bitmap, a number of bits that are reserved 
for future use (RFU), a branch table base pointer, a leaf 
table base pointer, and may include an indication as to 

10 how many of the blocks in the sub-trie below are sparse 
blocks. The indication as to how many blocks in the sub- 
trie below are sparse blocks can be used to optimize 
accesses to the sub-trie below. 
[0033] Dense blocks are used where the density of 

15 pointers within a stride prohibits the use of the more 
memory efficient sparse blocks. One example of a 
dense block 921 for an 8-bit stride is shown in Figure 1 2. 
[0034] Note that the large bitmaps included in the 
dense block above may be difficult for software to ma- 

20 nipulate, and the amount of data that has to be retrieved 
to process such a block is large. In addition, the fields 
within the block are not aligned to normal cache line 
boundaries, and the amount of contiguous memory that 
would likely be required for the leaf table and branch 

25 table would place restrictions on the dynamic allocation 
of memory in the implementation. However, the repre- 
sentation illustrated above does present the minimum 
memory usage for a dense block. In embodiments that 
include wide or separate memory structures, such a 

30 dense block structure may be practical. 

[0035] In other embodiments where the dense blocks 
such as that illustrated above are less practical, dense 
blocks may be broken up into records to facilitate both 
the hardware implementation of the system and efficient 

35 processing by software. This was briefly discussed 
above. For example, a 32 bit microprocessor would 
most likely prefer to manipulate 32 bit bitmaps. Thus, for 
an 8-bit stride, eight stride records could be used which 
are indexed using the upper three bits of the stride. Each 

40 of the records would then be used to process the lower 
five bits of the stride, where the bitmaps in a 5-bit dense 
stride record would be 32-bit bitmaps. 
[0036] In order to facilitate fetching of records for a 
subsequent stride, each record may include an indica- 

45 tion of the number of sparse records included in the fol- 
lowing stride block. If the sparse records are stored con- 
tiguously in the branch table before the dense records, 
indexing the branch table is simplified by keeping a 
count of the number of sparse records. 

50 [0037] Figure 13 illustrates a flow diagram of one 
method for compressing a dense stride block. At step 
1 02 the stride block is separated into a plurality of stride 
portions. This is analogous to separating the block into 
a number of records. For each stride portion, or record, 

55 steps 1 04-112 are performed. 

[0038] At step 104, the stride results for the portion 
are compressed to produce a compressed bitmap and 
a compressed list of stride results. This is the compres- 
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sion step illustrated in Figure 6. At step 106, the com- 
pressed bitmap and compressed list of stride results are 
further compressed to produce a leaf bitmap, branch bit- 
map, leaf table section and a branch table section. This 
is similar to the step shown in Figure 7 where the leaf 
table section corresponds to the set of leaf pointers in- 
cluded in the leaf pointer table for the stride portion, and 
the branch table section corresponds to the set of 
branch pointers for the stride portion. At step 108, the 
leaf table section is stored in the portion of memory or 
the table associated with the leaf pointers for the trie. 
Preferably, these leaf pointers are stored in a contiguous 
fashion within the leaf table starting at a leaf base pointer 
for the stride portion such that they can be accessed 
through the combination of a base pointer and offsets 
combined to produce indexes to the table. 
[0039] At step 1 1 0, the branch table section is stored 
in memory starting at a location corresponding to a 
branch base pointer. Preferably, it is stored in a contig- 
uous fashion in memory such that random access to the 
entries in the branch table can be performed using a 
base pointer and offsets. 

[0040] At step 1 1 0, a stride record is stored in memory 
for the stride portion where the stride record includes 
the leaf bitmap, the branch bitmap, the leaf table base 
pointer at which the leaf table section was stored, and 
the branch table base pointer at which the branch table 
section for the stride portion was stored. Storing the 
stride record at step 112 may include encoding the leaf 
bitmap and the branch bitmap in an extends bitmap and 
a type bitmap as was described with respect to Figure 
9 above. The extends bitmap and type bitmap enable 
the stride record to encode sparse and dense format d is- 
tinctions for subsequent stride blocks that are accessed 
via branch pointers included in the branch table. 
[0041] Figure 1 4 illustrates a block diagram of a pack- 
et routing circuit 250 that may be used in conjunction 
with the trie compression techniques discussed thus far 
to perform packet routing in a communications network. 
The packet routing circuit 250 includes memory 220, a 
determination block 200, packet memory 230, and out- 
put circuitry 240. Packets 202 received by the packet 
routing circuit 250 are stored in the packet memory 230 
while a forwarding decision for each packet is deter- 
mined. The address 203 for each packet is provided to 
the determination block 200 that determines the routing 
decision 242 for each packet. The determination block 
200 may be implemented as a state machine, discrete 
circuitry, or as a packet routing processor such as that 
illustrated in Figure 15. The determination block 200 is 
operably coupled to a memory 220 that stores a forward- 
ing table 222. Preferably, the forwarding table 222 is 
structured in a manner such that the forwarding deci- 
sions for packets are determined through the use of a 
compressed trie structure. The compressed trie struc- 
ture may include a number of strides where the block 
corresponding to each stride may be broken into a 
number of records. 



[0042] When the determination block 200 receives a 
packet address, it processes the address to determine 
a forwarding decision 242 in a manner similar to that 
illustrated in the flow diagram of Figure 16, which is de- 

5 scribed in additional detail below. In order to facilitate 
the determination of the forwarding decision 242, a 
cache 21 0 may be included in the packet routing circuit 
250. The cache 210, which is operably coupled to the 
memory 220 and the determination block 200, may be 

10 used to cache certain portions of the forwarding table 
222 such that the determination of the forwarding deci- 
sion 242 can be done in a more efficient manner that 
requires fewer accesses to the memory 220. 
[0043] Once a forwarding decision 242 has been de- 
ls termined by the determination block 200, it is provided 
to the output circuitry 240. For each packet, the output 
circuitry receives a forwarding decision 242 and for- 
wards the packet to at least one of the plurality of outputs 
246 based on the forwarding decision. 

20 [0044] Preferably, the packet routing circuit 250 is in- 
cluded in a router for use in a data communication net- 
work. Such a router may be used in a data communica- 
tions network that supports IP traffic. The memory 220 
may store a plurality of forwarding tables, where a par- 

25 ticular forwarding table is selected for use in determining 
the forwarding decision for a particular packet based on 
either a field included in the packet or the identity of an 
input port over which the packet was received. 
[0045] Figure 1 5 illustrates a packet routing processor 

30 300 that includes a processing module 302 and memory 
304. The packet routing processor preferably executes 
the method illustrated in Figure 16 through the use of 
software stored as a set of operational instructions in 
the memory 304. The processing module 302 may in- 

35 elude a single processing entity or a plurality of process- 
ing entities. Such a processing entity may be a micro- 
processor, a microcontroller, a digital signal processor 
or any device that processes information based on op- 
erational or programming instructions. 

40 [0046] The memory 304 may be a single memory de- 
vice or a plurality of memory devices. Such a memory 
device may be a read only memory device, random ac- 
cess memory device, floppy disk, hard drive memory, or 
any device that stores digital information. Note that the 

45 memory 304 may be incorporated in the memory 220 
included in the packet routing circuit or may be a sepa- 
rate memory structure. The memory 304 stores pro- 
gramming or operational instructions that, when execut- 
ed by the processing module 302, allow the processing 

so module 302 to perform packet routing functions such as 
those illustrated in the flow diagram of Figure 16. Note 
that the packet routing processor 300 may implement 
some of the functions of Figure 16 through software 
stored in the memory 304, whereas other portions may 

55 be implemented using hardware or circuitry included 
within the packet routing processor 300. Thus, in some 
embodiments a mix of hardware and software may be 
used to perform the method illustrated in Figure 16 
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[0047] Figure 1 6 illustrates a flow diagram of a meth- 
od for packet routing in a communications network. The 
method begins at step 402 where a packet is received. 
The packet includes an address that is used to deter- 
mine a forwarding decision for the packet. The forward- 
ing decision is determined based on a compressed trie 
structure that may be stored in a forwarding table. The 
compressed trie structure is preferably made up of a 
number of strides where the blocks that make up a stride 
may be divided into a number of records where the 
blocks and records are preferably structured as indicat- 
ed above. 

[0048] At step 404 a first stride block is fetched using 
a first portion of the address. As stated above, a stride 
block may be broken into a number of records in order 
to simplify processing. In one embodiment, the most sig- 
nificant bits of the address are used to retrieve a stride 
record included in a stride block, where the most signif- 
icant bits index between a number of stride records that 
make up a dense block within the trie structure. Each 
stride block includes a first bitmap, a second bitmap, a 
leaf table base pointer, and a branch table base pointer. 
Once the stride block has been fetched at step 404, it is 
processed using steps 406-416. 
[0049] At step 406, it is determined if the forwarding 
decision for the address can be fully determined based 
on the stride block that has been fetched. This is deter- 
mined based on at least one of the first and second bit- 
maps. The first bitmap is an extends bitmap and the sec- 
ond bitmap is a type bitmap, the extends bitmap alone 
can be used to determine if the forwarding decision is 
fully determined using this stride record. 
[0050] If the forwarding decision is fully determined 
using the stride block, the method proceeds to 408 
where a leaf table offset is generated from at least one 
of the first and second bitmaps and the second portion 
of the address. The second portion of the address is 
used to select a specific bit location within one or more 
of the bitmaps and a masking operation followed by a 
population count is used to determine an offset to the 
leaf table. The extends bitmap and type bitmap must be 
combined to generate the leaf bitmap. This can be ac- 
complished by performing a bit-wise AND operation of 
the type bitmap and the bit-wise inverse of the extends 
bitmap. 

[0051] At step 41 0, the leaf table offset generated at 
step 408 is combined with the leaf table base pointer to 
produce a leaf table index. This leaf table index is then 
used at step 41 2 to access the leaf table to retrieve the 
forwarding decision for the packet. The leaf table may 
either directly store the forwarding decisions, or may 
store pointers to a list of forwarding decisions. 
[0052] If it determined at step 406 that the forwarding 
decision is not fully determined in this stride, the method 
proceeds to step 41 4 where the steps necessary to fetch 
a subsequent stride record or block commence At step 
414 a branch table offset is generated from the second 
portion of the address and at least one of the first and 



second bitmaps. If sparse and dense blocks are sup- 
ported by the system in which the method of Figure 16 
is employed, generating the branch table offset may in- 
clude generating either a branch table offset to a sparse 

5 block or to a dense block. The sparse and dense dis- 
tinction and the encodings necessary for distinguishing 
between sparse and dense blocks were described with 
respect to Figure 9 above. Thus, extend and type bit- 
maps are required for distinguishing sparse and dense 

10 blocks. The generation of the branch table offset is per- 
formed using masking and popcount steps in a similar 
manner as those used to generate the leaf table offset. 
[0053] At step 416, the branch table offset is com- 
bined with a branch table base pointer to produce a 

15 branch table index. The branch table index is then used 
to retrieve a subsequent stride block at step 418. Step 
418 may include retrieving a subsequent block corre- 
sponding to a stride and then indexing to a particular 
record within the stride. It may also involve simply fetch - 

20 ing a subsequent sparse block in its entirety. 

[0054] A method that may be used for processing the 
dense blocks are illustrated in Figure 17, which has 
been included for added clarity. Figure 1 7 illustrates a 
flow diagram of a method for processing a dense block 

25 or record utilizing a portion of the address corresponding 
to the packet. At step 502 a particular bit within the bit- 
maps included for the dense record is selected using 
the address portion. At step 504 it is determined if the 
bit to which the address portion corresponds is set within 

30 the extends bitmap. If not, this indicates that a leaf will 
be reached during this record, and steps 506-516 are 
executed in order to retrieve a forwarding decision for 
that leaf. 

[0055] At step 506 the leaf bitmap is generated by bit- 

35 wise AN Ding the type bitmap with the bit-wise inverse 
of the extends bitmap. At step 508, it is determined if the 
bit to which the address portion corresponds in the leaf 
bitmap is set. If it is, the method proceeds to step 510, 
and if it is not, the method proceeds to step 509. At step 

40 509, a scan to the left in the leaf bitmap is performed to 
find the next set bit. At step 510, unwanted bits in the 
leaf bitmap generated at step 506 are masked off. The 
unwanted bits are those bits to the right of the set bit 
determined at step 506. 

45 [0056] At step 512, a popcount is performed on the 
remaining non-masked bits in the leaf bitmap in orderto 
determine a leaf offset. At step 514, the leaf offset is 
combined with the leaf base pointer for the record to 
generate a leaf index. This leaf index is then used at 

so step 51 6 to retrieve the forwarding decision for the pack- 
et. 

[0057] If it is determined at step 504 that the bit in the 
extends bitmap corresponding to the portion of the ad- 
dress is set, this indicates that a subsequent block must 
55 be fetched in order to further process the address. As 
such, the method proceeds to step 518. At step 518 rt 
is determined if the bit corresponding to the address por- 
tion is also set in the type bitmap, where the type bitmap 
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indicates whether or not the subsequent block to be 
fetched is sparse or dense. If the bit is set at 518, a 
dense block is to be processed, and the method pro- 
ceeds to step 520. 

[0058] At step 520, the dense entry bitmap is gener- s 
ated by bit-wise ANDing the type and extends bitmaps 
together. Unwanted bits in the dense entry bitmap are 
masked off at step 522, where those bits to the right of 
that selected by the address portion are masked. At step 
524, a popcount is performed on the remaining non- io 
masked bits in order to determine a dense offset. 
[0059] At step 526, the dense offset is combined with 
a dense base pointer to generate the dense index. As- 
suming that all sparse blocks are contiguously stored 
based on a branch base pointer, and all dense blocks 15 
are stored immediately following the sparse blocks (also 
contiguously), the dense base pointer may be deter- 
mined by adding the size of the number of sparse blocks 
included in the subsequent block to the branch base 
pointer. Thus, storing the number of sparse blocks in- 20 
eluded in a subsequent stride as described earlier can 
be used to efficiently generate pointers to subsequent 
dense stride blocks. The dense index generated at step 
526 can then be used at step 528 to retrieve the subse- 
quent dense stride block. Because the processing sys- 25 
tern already knows that the subsequent block is a dense 
block, it will be fetched and processed in the manner 
most efficient for dense blocks. 
[0060] If at step 51 8 it is determined that the bit cor- 
responding to the address portion is not set in the type 30 
bitmap, the subsequent record to be fetched is a sparse 
block. As such, a sparse entry bitmap is generated at 
step 530. This is accomplished by bit-wise ANDing the 
extends bitmap with the bit-wise inverse of the type bit- 
map. 35 
[0061] At step 532, unwanted bits in the sparse entry 
bitmap are masked off. At step 534, a popcount is per- 
formed to determine a sparse offset. The sparse offset 
is combined with a sparse base pointer at step 536 to 
generate a sparse index. Note that if the sparse records *o 
for the subsequent stride are all stored contiguously pri- 
orto the dense records, the sparse base pointerwill sim- 
ply be the branch base pointerfor the subsequent stride. 
At step 538, the subsequent sparse stride record is re- 
trieved using the sparse index generated at step 536. 45 
[0062] The methodology for processing a sparse 
stride record or block is similar to that for processing a 
dense record. The exception is that rather than checking 
the extends and type bitmaps at a particular bit location 
corresponding to the portion of the address, a compar- so 
ison must first be performed with the values included in 
the sparse record. If a match is determined, the bit lo- 
cation corresponding to that value in the extends and 
type bitmaps is consulted to determine if a leaf has been 
reached or if a subsequent sparse or dense record must 55 
be fetched. If no match is determined, the next higher 
value is selected, and the bit location corresponding to 
that value is referenced in the bitmaps. As stated earlier, 
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this is analogous to performing a scan left operation in 
a dense bit map. 

[0063] Figure 1 8 illustrates a graphical representation 
of the determination of a leaf table pointer 750 utilizing 
an address 702 that is provided as an example to sup- 
plement the discussion above. A first portion of the ad- 
dress 704 is applied to a block corresponding to the first 
stride in the trie structure that stores the potential prefix 
matches for the address. The first portion of the address 
704 indexes through this dense block to select the 
dense record 706. Although the first stride is shown to 
process 8 bits of the address 702, in other embodi- 
ments, the first stride may process 16 bits of the ad- 
dress. Processing the first 16 bits of the address in a 
single stride may allow the average number of memory 
accesses required to process an address to be reduced 
at the cost of additional memory. Thus, the number of 
bits processed in each stride of a system may be select- 
ed based on both speed and memory considerations. 
[0064] In one embodiment, it is assumed that the first 
block of the trie structure is always encoded as a dense 
block. As is apparent to one of ordinary skill in the art, 
this block may also be encoded as a sparse block in 
some circumstances, but in embodiments that support 
sparse or dense encoding of the first block, an external 
variable that indicates the type of encoding used must 
be available such that processing of the first block is 
properly performed. 

[0065] The bitmaps 708 for the dense record 706 are 
processed via a function 707, which processes the bit- 
maps using a second portion of the address 705 to gen- 
erate an offset 709. Note that this assumes that the ad- 
dress 702 will require multiple records to determine the 
forwarding decision. If the forwarding decision were de- 
termined based on the dense record 706 alone, a leaf 
in the trie would have been reached during the first 
stride, and no further processing would be necessary. 
[0066] The offset 709 is combined with the branch ta- 
ble base pointer 71 0 for the dense record 706 to gener- 
ate a sparse block pointer 711 . The offset 709 was pref- 
erably determined in a manner that included a differen- 
tiation between subsequent blocks being sparse or 
dense. Thus, the processor will know that the next block 
to be fetched is sparse, and can be fetched and proc- 
essed accordingly. 

[0067] The sparse block pointer 71 1 is used to retrieve 
the sparse block 720. Because the sparse block 720 is 
sparse, the subsequent eight bits of the address that 
make up address portion 71 2 are used in comparison 
operations with each of the values included in the array 
of values of the sparse block 720. This value compari- 
son generates an offset 724 that is combined with a 
branch table base pointer 722 for the sparse block to 
generate a subsequent dense block base pointer 726. 
[0068] The dense block base pointer 726 points to the 
beginning of a dense block which is indexed through by 
a subsequent portion of the address 731 . This indexing 
selects a particular dense record 730 within the dense 
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block. The bitmaps 732 for the dense record 730 are 
provided to the function 707 along with address bits 737 
to produce the offset 733. The offset 733 is then com- 
bined with a branch table base pointer 734 for the dense 
record 730 to produce a sparse block pointer 735 that 5 
selects the sparse block 740. 
[0069] The final eight bits of the address 741 are then 
used to compare with the values stored in the sparse 
block to produce the offset 744. The offset 744 is com- 
bined with the leaf table base pointer 742 of the sparse 10 
block 740 to generate the leaf table index 750. The leaf 
table index 750 can then be used to access the leaf table 
and retrieve the forwarding decision for the packet. It 
should be noted that dense and sparse blocks can be 
combined in any order when processing an address. 15 
Figure 18 illustrates one example of one such combina- 
tion. 

[0070J The present invention provides a means for 
compressing the data associated with strides in trie 
structures in a manner that improves memory usage 20 
and reduces the average number of memory access re- 
quired to determine a forwarding decision for a packet. 
As such, higher speed networks can be supported with- 
out the need for impractically large memory structures 
to store the trie structures. Utilization of the compressed 25 
data structures requires only linear operations, thus re- 
ducing the overall cost and complexity of the packet for- 
warding system. 

[0071] In the foregoing specification, the invention 
has been described with reference to specific embodi- 30 
ments. However, one of ordinary skill in the art appreci- 
ates that various modifications and changes can be 
made without departing from the scope of the present 
invention as set forth in the claims below. Accordingly, 
the specification and figures are to be regarded in an 35 
illustrative rather than a restrictive sense, and all such 
modifications are intended to be included within the 
scope of present invention. 

[0072] Benefits, other advantages, and solutions to 
problems have been described above with regard to *o 
specific embodiments. However, the benefits, advan- 
tages, solutions to problems, and any element(s) that 
may cause any benefit, advantage, or solution to occur 
or become more pronounced are not to be construed as 
a critical, required, or essential feature or clement of any 
or all the claims. As used herein, the terms "comprises," 
"comprising," or any other variation thereof, are intend- 
ed to cover a non-exclusive inclusion, such that a proc- 
ess, method, article, or apparatus that comprises a list 
of elements does not include only those elements but so 
may include other elements not expressly listed or in- 
herent to such process, method, article, or apparatus. 
Where technical features mentioned in any claim are fol- 
lowed by reference signs, thos reference signs have 
been included for the sole purpose of increasing the in- 55 
telligtbilit of the claims and accordingly, such reference 
signs do not have any limiting effect 0 the scope of each 
element identified by way of example by such reference 



signs. 
Claims 

1. A method for packet routing, comprising: 

receiving a packet that includes an address; 

fetching a first stride block based on a first por- 
tion of the address, wherein each stride block 
includes a first bitmap, a second bitmap, a leaf 
table base pointer, and a branch table base 
pointer; 

processing the first stride block, wherein 
processing a stride block includes: 

determining if a forwarding decision is de- 
termined based on a second portion of the 
address and at least one of the first and 
second bitmaps of the stride block; 

when the forwarding decision is deter- 
mined based on at least one of the first and 
second bitmaps: 

generating a leaf table offset from at 
least one of the first and second bit- 
maps and the second portion of the ad- 
dress; 

combining the leaf table offset with the 
leaf table base pointer to produce a 
leaf table index; and 

accessing a leaf table using the leaf ta- 
ble index to retrieve the forwarding de- 
cision; 

when the forwarding decision is not deter- 
mined based on the second portion of the 
address and at least one of the first and 
second bitmaps; 

generating a branch table offset from 
the second portion of the address and 
at least one of the first and second bit- 
maps; 

combining the branch table offset with 
the branch table base pointer to pro- 
duce a branch table index; 
accessing a branch table using the 
branch table index to retrieve a subse- 
quent stride block; and 

processing the subsequent stride block and 
any additional subsequent stride blocks gener- 
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ated using additional portions of the address 
until the forwarding decision is retrieved. 

The method of claim 1 , wherein the first bitmap is a 
leaf bitmap and the second bitmap is a branch bit- 5 
map, wherein determining if a forwarding decision 
is determined further comprises determining if the 
forwarding decision is determined based on the 
second portion of the address and the leaf and 
branch bitmaps, wherein generating the leaf table 10 
offset further comprises generating the leaf table 
offset from the second portion of the address and 
the leaf bitmap, and wherein generating the branch 
table offset further comprises generating the branch 
table offset from the second portion of the address 15 
and the branch bitmap. 

The method of claim 2, wherein generating the leaf 
table offset further comprises: 

20 

masking off a portion of the leaf bitmap to pro- 
duce a masked leaf bitmap, wherein the portion 
of the leaf bitmap that is masked off is deter- 
mined based on the second portion of the ad- 
dress; and 25 
performing a population count on the masked 
leaf bitmap to produce the leaf offset. 

The method of claim 2, wherein generating the 
branch table offset further comprises: 30 

masking off a portion of the branch bitmap to 
produce a masked branch bitmap, wherein the 
portion of the branch bitmap that is masked off 
is determined based on the second portion of 35 
the address; and 

performing a population count on the masked 
branch bitmap to produce the branch offset. 

40 

The method of claim, 1 , wherein accessing the leaf 
table using the leaf table index to retrieve the for- 
warding decision further comprises: 

accessing the leaf table to retrieve a pointer to 45 
the forwarding decision; and 

retrieving the forwarding decision using the 
pointer to the forwarding decision. 

50 

The method of claim 1, wherein the first bitmap is 
an extends bitmap and the second bitmap is a type 
bitmap, wherein determining if a forwarding deci- 
sion is determined further comprises determining if 
the forwarding decision is determined based on the 55 
second portion of the address and the extends bit- 
map, wherein generating the leaf tabfe offset further 
comprises generating the leaf table offset from the 



second portion of the address and the extends and 
type bitmaps, and wherein generating the branch 
table offsetfurther comprises generating the branch 
table offset from the second portion of the address 
and the extends and type bitmaps. 

7. The method of claim 6, wherein generating the leaf 
table offset further comprises: 

combining the extends bitmap and the type bit- 
map to generate a leaf bitmap; 

masking off a portion of the leaf bitmap to pro- 
duce a masked leaf bitmap, wherein the portion 
of the leaf bitmap that is masked off is deter- 
mined based on the second portion of the ad- 
dress; and 

performing a population count on the masked 
leaf bitmap to produce the leaf offset. 

8. The method of claim 6, wherein generating the 
branch table offset further comprises: 

combining the extends bitmap and the type bit- 
map to generate a branch bitmap; 

masking off a portion of the branch bitmap to 
produce a masked branch bitmap, wherein the 
portion of the branch bitmap that is masked off 
is determined based on the second portion of 
the address; and 

performing a population count on the masked 
branch bitmap to produce the branch offset. 

9. The method of claim 8, wherein the type bitmap 
identifies each subsequent stride block as one of a 
sparse stride block and a dense stride block. 

10. The method of claim 9, wherein subsequent stride 
blocks for each stride block are stored in contiguous 
sets. 

11. The method of claim 10, wherein sparse blocks are 
grouped together and dense blocks are grouped to- 
gether in the contiguous sets. 

12. A packet routing processor, comprising: 

a processing module; and 

memory operably coupled to the processing 
module, wherein the memory stores operating 
instructions such that, when executed by the 
processing module, the operating instructions 
cause the processing module to perform the 
functions of: 
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fetching a first stride block based on a first 
portion of an address for a received packet, 
wherein each stride block includes a first 
bitmap, a second bitmap, a leaf table base 
pointer, and a branch table base pointer; s 

processing the first stride block, wherein 
processing a stride block includes: 

determining if a forwarding decision is 10 
determined based on a second portion 
of the address and at least one of the 
first and second bitmaps of the stride 
block; 

15 

when the forwarding decision is deter- 
mined based on at least one of the first 
and second bitmaps: 

generating a leaf table offset from 20 
at least one of the first and second 
bitmaps and the second portion of 
the address; 

combining the leaf table offset with 25 
the leaf table base pointer to pro- 
duce a leaf table index; and 

accessing a leaf table using the 
leaf table index to retrieve the for- 30 
warding decision; 



when the forwarding decision is not 
determined based on the second por- 
tion of the address and at least one of 
the first and second bitmaps; 

generating a branch table offset 
from the second portion of the ad- 
dress and at least one of the first 
and second bitmaps; 

combining the branch table offset 
with the branch table base pointer 
to produce a branch table index; 

accessing a branch table using 
the branch table index to retrieve 
a subsequent stride block; and 

processing the subsequent stride block and 
any additional subsequent stride blocks gener- 
ated using additional portions of the address 
until the forwarding decision is retrieved. 

13. The packet routing processor of claim 12, wherein 
the first bitmap is a leaf bitmap and the second bit- 
map is a branch bitmap, wherein determining if a 



forwarding decision is determined further compris- 
es determining if the forwarding decision is deter- 
mined based on the second portion of the address 
and the leaf and branch bitmaps, wherein generat- 
ing the leaf table offset further comprises generat- 
ing the leaf table offset from the second portion of 
the address and the leaf bitmap, and wherein gen- 
erating the branch table offset further comprises 
generating the branch table offset from the second 
portion of the address and the branch bitmap. 

14. The packet routing processor of claim 13, wherein 
generating the leaf table offset further comprises: 

masking off a portion of the leaf bitmap to pro- 
duce a masked leaf bitmap, wherein the portion 
of the leaf bitmap that is masked off is deter- 
mined based on the second portion of the ad- 
dress; and 

performing a population count on the masked 
leaf bitmap to produce the leaf offset. 

15. The packet routing processor of claim 13, wherein 
generating the branch table offset further compris- 
es: 

masking off a portion of the branch bitmap to 
produce a masked branch bitmap, wherein the 
portion of the branch bitmap that is masked off 
is determined based on the second portion of 
the address; and 

performing a population count on the masked 
35 branch bitmap to produce the branch offset. 

16. The packet routing processor of claim 12, wherein 
accessing the leaf table using the leaf table index 
to retrieve the forwarding decision further compris- 

40 es: 

accessing the leaf table to retrieve a pointer to 
the forwarding decision; and 

45 retrieving the forwarding decision using the 

pointer to the forwarding decision. 

17. The packet routing processor of claim 12, wherein 
the first bitmap is an extends bitmap and the second 

so bitmap is a type bitmap, wherein determining if a 
forwarding decision is determined further compris- 
es determining if the forwarding decision is deter- 
mined based on the second portion of the address 
and the extends bitmap, wherein generating the leaf 

55 table off set further com prises generating the leaf ta- 
ble offset from the second portion of the address 
and the extends and type bitmaps, and wherein 
generating the branch table offset further comprises 
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generating the branch table offset from the second 
portion of the address and the extends and type bit- 
maps. 

18. The packet routing processor of claim 17, wherein 
generating the leaf table offset further comprises: 

combining the extends bitmap and the type bit- 
map to generate a leaf bitmap; 

masking off a portion of the leaf bitmap to pro- 
duce a masked leaf bitmap, wherein the portion 
of the leaf bitmap that is masked off is deter- 
mined based on the second portion of the ad- 
dress; and 

performing a population count on the masked 
leaf bitmap to produce the leaf offset. 

19. The packet routing processor of claim 17, wherein 
generating the branch table offset further compris- 
es: 

combining the extends bitmap and the type bit- 
map to generate a branch bitmap; 

masking off a portion of the branch bitmap to 
produce a masked branch bitmap, wherein the 
portion of the branch bitmap that is masked off 
is determined based on the second portion of 
the address; and 

performing a population count on the masked 
branch bitmap to produce the branch offset. 

20. The packet routing processor of claim 19, wherein 
the type bitmap identifies each subsequent stride 
block as one of a sparse stride block and a dense 
stride block. 

21. The packet routing processor of claim 20, wherein 
dense stride blocks store subsequent sparse stride 
blocks and subsequent dense stride blocks in con- 
tiguous sets. 

22. A packet routing circuit, comprising: 



10 



15 



20 



25 



30 



35 



40 



45 



a packet memory receives packets and stores 
the packets prior to forwarding, wherein each 
packet includes an address; so 

output circuitry operably coupled to the packet 
memory, wherein for each packet, the output 
circuitry receives a forwarding decision and for- 
wards the packet to at least one of a plurality of 55 
outputs based on the forwarding decision; 

memory that stores a forwarding table, wherein 



the forwarding table stores forwarding deci- 
sions for the packets; and 

a determination block operably coupled to the 
memory and the output circuitry, wherein the 
determination block receives the address for 
each packet and determines the forwarding de- 
cision for the packet, wherein the determination 
block provides the forwarding decision for the 
packet to the output circuitry such that the pack- 
et is forwarded to at least one of the outputs, 
wherein determining the forwarding decision 
for the packet includes: 

fetching a first stride block from the for- 
warding table stored in the memory based 
on a first portion of an address for a re- 
ceived packet, wherein each stride block 
includes a first bitmap, a second bitmap, a 
leaf table base pointer, and a branch table 
base pointer; 

processing the first stride block, wherein 
processing a stride block includes: 

determining if a forwarding decision is 
determined based on a second portion 
of the address and at least one of the 
first and second bitmaps of the stride 
block; 

when the forwarding decision is deter- 
mined based on at least one of the first 
and second bitmaps: 

generating a leaf table offset from 
at least one of the first and second 
bitmaps and the second portion of 
the address; 

combining the leaf table offset with 
the leaf table base pointer to pro- 
duce a leaf table index; and 

accessing a leaf table stored in the 
memory using the leaf table index 
to retrieve the forwarding deci- 
sion; 

when the forwarding decision is not 
determined based on the second por- 
tion of the address and at least one of 
the first and second bitmaps; 

generating a branch table offset 
from the second portion of the ad- 
dress and at least one of the first 
and second bitmaps; 
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combining the branch table offset 
with the branch table base pointer 
to produce a branch table index; 

accessing a branch table stored in 
the memory using the branch ta- 
ble index to retrieve a subsequent 
stride block; and 

processing the subsequent stride block 
and any additional subsequent stride 
blocks generated using additional portions 
of the address until the forwarding decision 
is retrieved. 

23. The packet routing circuit of claim 22 further com- 
prises a cache operabty coupled to the memo ry and 
the determination block, wherein the cache stores 
at least a portion of the forwarding table. 

24. The packet routing circuit of claim 22, wherein the 
memory stores a plurality of forwarding tables, 
wherein a particular forwarding table is selected for 
use in determining the forwarding decision for a par- 
ticular packet based on at least one of a field includ- 
ed in the particular packet and an identity of an input 
port to the packet routing circuit over which the par- 
ticular packet was received. 

25. The packet routing circuit of claim 22, wherein the 
determination block further comprises: 

a processing module; and 

an instruction memory operably coupled to the 
processing module, wherein the instruction 
memory stores instructions that, when execut- 
ed by the processing module, cause the 
processing module to perform functions neces- 
sary to determine the forwarding decision for 
the packet. 

26. The packet routing circuit of claim 22, wherein the 
determination block further comprises a state ma- 
chine. 

27. The packet routing circuitry of claim 22, wherein the 
packet routing circuitry is included in a router. 

28. The packet routing circuit of claim 27, wherein the 
packets are internet protocol (IP) packets. 

29. The packet routing circuit of claim 22, wherein the 
determination block utilizes population counts to 
determine branch and leaf offsets. 

30. The packet routing circuit of claim 22, wherein the 
determination block utilizes linear operations to de- 



termine the forwarding decision for each of the 
packets. 

31 . A method for compressing a stride included in a trie 
5 structure, wherein the stride includes a plurality of 
nodes, comprising: 

separating the stride into a plurality of stride 
portions, wherein each stride portion includes 
10 stride results for a portion of the plurality of 

nodes, wherein a stride result is one of a leaf 
pointer and a branch pointer; and 

for each stride portion: 

15 

compressing the stride results for the stride 
portion using run length encoding to pro- 
duce a compression bitmap and a com- 
pressed list of stride results; 

20 

generating a leaf bitmap, a branch bitmap, 
a leaf table section, and a branch table sec- 
. tion from the compression bitmap and the 
compressed list of stride results; 

25 

storing the leaf table section in a leaf table 
at a leaf table base pointer for the stride 
portion; 

30 storing the branch table section in a branch 

table at a branch table base pointer for the 
stride portion; and 

storing a stride block in memory for the 
35 stride portion, wherein the stride block in- 

cludes the leaf bitmap, the branch bitmap, 
the leaf table base pointer, and the branch 
table base pointer. 

40 32. The method of claim 31 , wherein compressing the 
results for a stride block further comprises selecting 
one of a sparse compression format and a dense 
compression format based on a number of com- 
pressed stride results; and wherein 

45 

storing the stride block in memory further com- 
prises storing the stride block in the selected 
one of the sparse compression format and the 
dense compression format. 

50 

33. The method of claim 32, wherein the leaf bitmap 
and branch bitmap for each stride block are encod- 
ed in an extends bitmap and a type bitmap, wherein 
the extends bitmap and type bitmap for each stride 
55 block encode sparse and dense format distinctions 
for stride blocks accessed via branch pointers in- 
cluded in the branch table. 
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34. The method of claim 33, wherein the sparse com- 
pression format includes a value array correspond- 
ing to values for address bits used to access the 
stride block, and wherein the dense compression 
format includes bitmaps corresponding to the ad- 5 
dress bits, wherein a quantity of memory required 

to store the stride block in the sparse compression 
format is less than a quantity of memory required to 
store the stride block in a dense compression for- 
mat. 10 

35. A method for packet routing, comprising: 

receiving a packet that includes an address; 

15 

fetching a first stride block, wherein the first 
stride block encodes a first portion of a longest 
prefix match trie, wherein the first stride block 
is one of a sparse stride block and a dense 
stride block, wherein sparse stride blocks en- 20 
code portions of the longest prefix match trie 
that include no more than a first number of 
nodes, wherein dense stride blocks encode 
portions of the longest prefix match trie that in- 
clude more than the first number of nodes; 25 

comparing a first portion of the address with a 
first portion of the first stride block to determine 
if a forwarding decision for the packet is re- 
solved by the first stride block; 30 

when the forwarding decision is resolved by the 
first stride block, determining the forwarding 
decision for the packet; 

35 

when the forwarding decision for the packet is 
not resolved by the first stride block: 

determining a second stride block based 
on the first portion of the address and a 40 
second portion of the first stride block; and 

processing the second stride block and any 
subsequent stride blocks determined until 
the forwarding decision is determined, 45 
wherein processing a stride block includes 
fetching the stride block and comparing a 
portion of the address with a portion of the 
stride block to determine one of the for- 
warding decision and a subsequent stride so 
block for processing; and 

forwarding the packet based on the for- 
warding decision. 

55 

36. The method of claim 35, wherein when the first 
stride block is a dense stride block, comparing a first 
portion of the address with the portion of the first 



stride block further comprises: 

selecting a stride record of a plurality of stride 
records included in the first stride block using a 
first set of bits in the first portion of the address, 
wherein each stride record of the plurality of 
stride records encodes a portion of nodes en- 
coded by the first stride block; and 
comparing a second set of bits in the first por- 
tion of the address with a portion of the stride 
record to determine if the forwarding decision 
is resolved by the first stride block. 
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